These procedures are analogous to the X library procedures with similar
names, such as XXXXCCCCoooonnnnffffiiiigggguuuurrrreeeeWWWWiiiinnnnddddoooowwww. Each one of the above procedures calls
the corresponding X procedure and also saves the configuration
information in Tk's local structure for the window. This allows the
information to be retrieved quickly by the application (using macros such
as TTTTkkkk____XXXX and TTTTkkkk____HHHHeeeeiiiigggghhhhtttt) without having to contact the X server. In
addition, if no X window has actually been created for _t_k_w_i_n yet, these
procedures do not issue X operations or cause event handlers to be
invoked; they save the information in Tk's local structure for the
window; when the window is created later, the saved information will be
used to configure the window.
See the X library documentation for details on what these procedures do
and how they use their arguments.
In the procedures TTTTkkkk____CCCCoooonnnnffffiiiigggguuuurrrreeeeWWWWiiiinnnnddddoooowwww, TTTTkkkk____MMMMoooovvvveeeeWWWWiiiinnnnddddoooowwww, TTTTkkkk____RRRReeeessssiiiizzzzeeeeWWWWiiiinnnnddddoooowwww,
TTTTkkkk____MMMMoooovvvveeeeRRRReeeessssiiiizzzzeeeeWWWWiiiinnnnddddoooowwww, and TTTTkkkk____SSSSeeeettttWWWWiiiinnnnddddoooowwwwBBBBoooorrrrddddeeeerrrrWWWWiiiiddddtttthhhh, if _t_k_w_i_n is an internal
window then event handlers interested in configure events are invoked
immediately, before the procedure returns. If _t_k_w_i_n is a top-level |
window then the event handlers will be invoked later, after X has seen
the request and returned an event for it.
Applications using Tk should never call procedures like XXXXCCCCoooonnnnffffiiiigggguuuurrrreeeeWWWWiiiinnnnddddoooowwww
directly; they should always use the corresponding Tk procedures.
The size and location of a window should only be modified by the
appropriate geometry manager for that window and never by a window itself
(but see TTTTkkkk____MMMMoooovvvveeeeTTTToooopppplllleeeevvvveeeellllWWWWiiiinnnnddddoooowwww for moving a top-level window).
You may not use TTTTkkkk____CCCCoooonnnnffffiiiigggguuuurrrreeeeWWWWiiiinnnnddddoooowwww to change the stacking order of a
window (_v_a_l_u_e_M_a_s_k may not contain the CCCCWWWWSSSSiiiibbbblllliiiinnnngggg or CCCCWWWWSSSSttttaaaacccckkkkMMMMooooddddeeee bits). To
change the stacking order, use the procedure TTTTkkkk____RRRReeeessssttttaaaacccckkkkWWWWiiiinnnnddddoooowwww.
The procedure TTTTkkkk____SSSSeeeettttWWWWiiiinnnnddddoooowwwwCCCCoooolllloooorrrrmmmmaaaapppp will automatically add _t_k_w_i_n to the |
TTTTKKKK____CCCCOOOOLLLLOOOORRRRMMMMAAAAPPPP____WWWWIIIINNNNDDDDOOOOWWWWSSSS property of its nearest top-level ancestor if the new|
colormap is different from that of _t_k_w_i_n's parent and _t_k_w_i_n isn't already|
in the TTTTKKKK____CCCCOOOOLLLLOOOORRRRMMMMAAAAPPPP____WWWWIIIINNNNDDDDOOOOWWWWSSSS property.
BBBBUUUUGGGGSSSS
TTTTkkkk____SSSSeeeettttWWWWiiiinnnnddddoooowwwwBBBBaaaacccckkkkggggrrrroooouuuunnnnddddPPPPiiiixxxxmmmmaaaapppp and TTTTkkkk____SSSSeeeettttWWWWiiiinnnnddddoooowwwwBBBBoooorrrrddddeeeerrrrPPPPiiiixxxxmmmmaaaapppp differ slightly
from their Xlib counterparts in that the _p_i_x_m_a_p argument may not
necessarily be deleted immediately after calling one of these procedures.
This is because _t_k_w_i_n's window may not exist yet at the time of the call,
in which case _p_i_x_m_a_p is merely saved and used later when _t_k_w_i_n's window
is actually created. If you wish to delete _p_i_x_m_a_p, then call
TTTTkkkk____MMMMaaaakkkkeeeeWWWWiiiinnnnddddoooowwwwEEEExxxxiiiisssstttt first to be sure that _t_k_w_i_n's window exists and _p_i_x_m_a_p
